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Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The IETF Trust (2007). 
IESG Note 


This RFC is not a candidate for any level of Internet Standard. The 
IETF disclaims any knowledge of the fitness of this RFC for any 
purpose and in particular notes that the decision to publish is not 
based on IETF review for such things as security, congestion control, 
or inappropriate interaction with deployed protocols. The RFC Editor 
has chosen to publish this document at its discretion. Readers of 
this document should exercise caution in evaluating its value for 
implementation and deployment. See RFC 3932 for more information. 


Abstract 


This document consists of two primary components, a schema for agents 
that make use of the Lightweight Directory Access protocol (LDAP) and 
a proposed use case of that schema, for distributed configuration of 
similar directory user agents. A set of attribute types and an 
object class are proposed. In the proposed use case, directory user 
agents (DUAs) can use this schema to determine directory data 
location and access parameters for specific services they support. 

In addition, in the proposed use case, attribute and object class 
mapping allows DUAs to reconfigure their expected (default) schema to 
match that of the end user's environment. This document is intended 
to be a skeleton for future documents that describe configuration of 
Specific DUA services. 
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Le 


Background and Motivation 


LDAP [RFC4510] has brought about a nearly ubiquitous acceptance of 
the directory server. Many client applications (DUAs) are being 
created that use LDAP directories for many different services. And 
although the LDAP protocol has eased the development of these 
applications, some challenges still exist for both developers and 
directory administrators. 


The authors of this document are implementers of DUAs described by 
[RFC2307]. In developing these agents, we felt there were several 
issues that still need to be addressed to ease the deployment and 
configuration of a large network of these DUAs. 


One of these challenges stems from the lack of a utopian schema. A 
utopian schema would be one that every application developer could 
agree upon and that would support every application. Unfortunately 
today, many DUAs define their own schema, even when they provide 
similar services (like RFC 2307 vs. Microsoft’s Services for Unix 
[MSSFU]). These schemas contain similar attributes, but use 
different attribute names. This can lead to data redundancy within 
directory entries and cause directory administrators unwanted 
challenges, updating schemas and synchronizing data. Or, in a more 
common case, two or more applications may agree on common schema 
elements, but choose a different schema for other elements of data 
that might also be shareable between the applications. While data 
synchronization and translation tools exist, the authors of this 
document believe there is value in providing this capability in the 
directory user agent itself. 


Aside from proposing a schema for general use, one goal of this 
document is to eliminate data redundancy by having DUAs configure 
themselves to the schema of the deployed directory, instead of 
forcing the DUA’s own schema on the directory. 


Another goal of this document is to provide the DUA with enough 
configuration information so that it can discover how to retrieve its 
data in the directory, such as what locations to search in the 
directory tree. 


Finally, this document intends to describe a configuration method for 
DUAs that can be shared among many DUAs on various platforms, 
providing, as such, a configuration profile. The purpose of this 
profile is to centralize and simplify management of DUAs. 


This document is intended to provide the skeleton framework for 
future documents that will describe the individual implementation 
details for the particular services provided by that DUA. The 
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authors of this document plan to develop such a document for the 
Network Information Service DUA, described by RFC 2307 or its 
successor. 


We expect that as DUAs take advantage of this configuration scheme, 
each DUA will require additional configuration parameters, not 
specified by this document. Thus, we would expect that new auxiliary 
object classes that contain new configuration attributes will be 
created and then joined with the structural class defined by this 
document to create a configuration profile for a particular DUA 
service. By joining various auxiliary object classes for different 
DUA services, the configuration of various DUA services can be 
controlled by a single configuration profile entry. 


2. General Information 


The schema defined by this document is defined under the "DUA 
Configuration Schema". This schema is derived from the object 
identifier (OID): iso (1) org (3) dod (6) internet (1) private (4) 
enterprises (1) Hewlett-Packard Company (11) directory (1) LDAP-UX 
Integration Project (3) DUA Configuration Schema (1). This OID is 
represented in this document by the keystring "DUAConfSchemaOID" 
(1:3.,6.154.1.11.1.3.1). 


2.1. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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The following attributes are defined in this document: 


May 2007 


preferredServerList 
defaultServerList 
defaultSearchBase 
defaultSearchScope 
authenticationMethod 
credentialLevel 
serviceSearchDescriptor 
serviceCredentialLevel 
serviceAuthenticationMethod 
attributeMap 
objectclassMap 
searchTimeLimit 
bindTimeLimit 
followReferrals 
dereferenceAliases 
profileTTL 


2.3. Object Classes Summary 


The following object class is defined in this document: 


DUAConfigProfile 


2.4. Common Syntax/Encoding Definitions 


The proposed string encodings used by the attributes defined in this 


document can be found in Section 4. 
[RFC4234] for defining new encodings. 


This document makes use of ABNF 


The following syntax definitions are used throughout this document. 
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The list of used syntaxes are: 


4R-—------------------------- toa E + 

| Key | Source | 

A = PaaS SSS Sa Ss eae eS + 

| keystring | as defined by [RFC4512] Section 1.4 | 

| descr | as defined by [RFC4512] Section 1.4 | 

| SP | as defined by [RFC4512] Section 1.4 | 

| WSP | as defined by [RFC4512] Section 1.4 
base as defined by distinguishedName in 

| | [RFC4514] | 

| distinguishedName | as defined by [RFC4514] Section 2 

| relativeDistinguishedName | as defined by [RFC4514] Section 2 | 

| scope | as defined by [RFC4516] Section 2 | 

| host | as defined by [RFC3986] Section 3.2.2 | 

| hostport | host [":" port ] | 
port as defined by [RFC3986] Section 3.2.3 

| serviceID | same as keystring 

tana = Fa A EN E A E + 


This document does not define new syntaxes that must be supported by 
the directory server. Instead, these syntaxes are merely expected to 
be interpreted by the DUA. As referenced in the schema definition in 
Section 3, most encodings are expected to be stored in attributes 
using common syntaxes, such as the Directory String syntax, as 
defined in Section 3.3.6 of [RFC4517]. Refer to RFC 4517 for 
additional syntaxes used by this schema. 


Schema Definition 


This section defines a proposed schema. This schema does not require 
definition of new matching rules or syntaxes, and it may be used for 
any purpose seen. A proposed use of this schema to support elements 
of configuration of a directory user agent is described in Section 4. 


.l. Attribute Definitions 


This section contains attribute definitions used by agents. The 
syntax used to describe these attributes is defined in [RFC4512], 
Section 4.1.2. Individual syntaxes and matching rules used within 
these descriptions are described in [RFC4517], Sections 3.3 and 4.2, 
respectively. 
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1.3.6.1.4.1.11.1.3.1.1.0 NAME 'defaultServerList' 
DESC 'List of default servers' 

EQUALITY caseIgnoreMatch 

SUBSTR caselgnoreSubstringsMatch 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE ) 


1.3.6.1.4.1.11.1.3.1.1.1 NAME ’defaultSearchBase’ 
DESC 'Default base for searches’ 

EQUALITY distinguishedNameMatch 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 
SINGLE-VALUE ) 


1.3.6.1.4.1.11.1.3.1.1.2 NAME ’preferredServerList’ 


DESC 'List of preferred servers' 
EQUALITY caseIgnoreMatch 

SUBSTR caselIgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE ) 


1.3.6.1.4.1.11.1.3.1.1.3 NAME ’searchTimeLimit’ 


DESC 'Maximum time an agent or service allows for a 


search to complete" 

EQUALITY integerMatch 

ORDERING integerOrderingMatch 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
SINGLE-VALUE ) 


1.3.6.1.4.1.11.1.3.1.1.4 NAME 'bindTimeLimit' 


DESC 'Maximum time an agent or service allows for a 


bind operation to complete’ 

EQUALITY integerMatch 

ORDERING integerOrderingMatch 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
SINGLE-VALUE ) 


1.3.6.1.4.1.11.1.3.1.1.5 NAME ’followReferrals’ 


DESC 'An agent or service does or should follow referrals' 


EQUALITY booleanMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 
SINGLE-VALUE ) 
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( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod' 
DESC 'Identifies the types of authentication methods either 
used, required, or provided by a service or peer’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE ) 


( 1.3.6.1.4.1.11.1.3.1.1.7 NAME 'profileTTl' 
DESC 'Time to live, in seconds, before a profile is 
considered stale’ 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
SINGLE-VALUE ) 


( 1.3.6.1.4.1.11.1.3.1.1.9 NAME 'attributeMap' 
DESC 'Attribute mappings used, required, or supported by an 
agent or service' 
EQUALITY caseIgnoreIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 


( 1.3.6.1.4.1.11.1.3.1.1.10 NAME 'credentialLevel' 
DESC 'Identifies type of credentials either used, required, 
or supported by an agent or service' 
EQUALITY caseIgnoreIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
SINGLE-VALUE ) 


( 1.3.6.1.4.1.11.1.3.1.1.11 NAME 'objectclassMap"' 
DESC 'Object class mappings used, required, or supported by 
an agent or service’ 
EQUALITY caseIgnoreIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 


( 1.3.6.1.4.1.11.1.3.1.1.12 NAME 'defaultSearchScope' 
DESC 'Default scope used when performing a search’ 
EQUALITY caseIgnoreIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
SINGLE-VALUE ) 
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( 1.3.6.1.4.1.11.1.3.1.1.13 NAME 'serviceCredentialLevel' 
DESC 'Specifies the type of credentials either used, required, 
or supported by a specific service’ 
EQUALITY caseIgnoreIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 


( 1.3.6.1.4.1.11.1.3.1.1.14 NAME 'serviceSearchDescriptor' 
DESC 'Specifies search descriptors required, used, or 
supported by a particular service or agent’ 

EQUALITY caseExactMatch 
SUBSTR caseExactSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 


( 1.3.6.1.4.1.11.1.3.1.1.15 NAME ’serviceAuthenticationMethod’ 
DESC 'Specifies types authentication methods either 
used, required, or supported by a particular service’ 
EQUALITY caseIgnoreMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX. 1:320:1.4.1.1466.115.121.1.15 ) 


( 1.3.6.1.4.1.11.1.3.1.1.16 NAME ’dereferenceAliases’ 
DESC 'Specifies if a service or agent either requires, 
supports, or uses dereferencing of aliases.’ 

EQUALITY booleanMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 
SINGLE-VALUE ) 


3.2. Class Definition 


The object class below is constructed from the attributes defined in 
Section 3.1, with the exception of the "cn" attribute, which is 
defined in [RFC4519]. "cn" is used to represent the name of the DUA 
configuration profile and is recommended for the relative 
distinguished name (RDN) [RFC4514] naming attribute. This object 
class is used specifically by the DUA described in Section 4. The 
syntax used to describe this object class is defined in [RFC4512], 
Section 4.1.1. 
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( 1.3.6.1.4.1.11.1.3.1.2.5 NAME ’DUAConfigProfile’ 

SUP top STRUCTURAL 

DESC 'Abstraction of a base configuration for a DUA' 

MUST ( cn ) 

MAY ( defaultServerList $ preferredServerList $ 
defaultSearchBase $ defaultSearchScope $ 
searchTimeLimit $ bindTimeLimit $ 
credentialLevel $ authenticationMethod $ 
followReferrals $ dereferenceAliases $ 
serviceSearchDescriptor $ serviceCredentialLevel $ 
serviceAuthenticationMethod $ objectclassMap $ 
attributeMap $ profileTTL ) ) 


4. DUA Implementation Details 


This section describes an implementation of the schema described in 
Section 3. Details about how a DUA should format and interpret the 
defined attributes are described below. Agents that make use of the 
DUAConfigProfile object class are expected to follow the 
Specifications in this section. 


Note: Many of the subsections below contain examples. Unless 
otherwise specified, these examples are rendered using the LDAP Data 
Interchange Format (LDIF) [RFC2849]. 


4.1. Interpreting the preferredServerList Attribute 


Interpretation: 


As described by the syntax, the preferredServerList parameter is a 
whitespace-separated list of server addresses and associated port 
numbers. When the DUA needs to contact a directory server agent 
(DSA), the DUA MUST first attempt to contact one of the servers 
listed in the preferredServerList attribute. The DUA MUST contact 
the DSA specified by the first server address in the list. If 
that DSA is unavailable, the remaining DSAs MUST be queried in the 
order provided (left to right) until a connection is established 
with a DSA. Once a connection with a DSA is established, the DUA 
SHOULD NOT attempt to establish a connection with the remaining 
DSAs. The purpose of enumerating multiple DSAs is not for 
supplemental data, but for high availability of replicated data. 
This is also the main reason why an LDAP URL [RFC3986] syntax was 
not selected for this document. 


If the DUA is unable to contact any of the DSAs specified by the 


preferredServerList, the defaultServerList attribute MUST be 
examined, as described in Section 4.2. The servers identified by 
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the preferredServerList MUST be contacted before attempting to 
contact any of the servers specified by the defaultServerList. 


Syntax: 
serverList - hostport *(SP [hostport]) 
Default Value: 


The preferredServerList attribute does not have a default value. 
Instead a DUA MUST examine the defaultServerList attribute. 


Other attribute notes: 


This attribute is used in conjunction with the defaultServerList 
attribute. Please see Section 4.2 for additional implementation 
notes. Determining how the DUA should query the DSAs also depends 
on the additional configuration attributes, credentialLevel, 
serviceCredentialLevel, bindTimeLimit, 
serviceAuthenticationMethod, and authenticationMethod. Please 
review Section 5 for details on how a DUA should properly bind to 
a DSA. 


Example: 


preferredServerList: 192.168.169.170 ldapl.mycorp.com 
1dap2:1389 [1080::8:800:200C:417A] :389 


4.2. Interpreting the defaultServerList Attribute 
Interpretation: 


The defaultServerList attribute MUST only be examined if the 
preferredServerList attribute is not provided, or the DUA is 
unable to establish a connection with any of the DSAs specified by 
the preferredServerList. 


If more than one address is provided, the DUA may choose either to 
accept the order provided or to create its own order, based on 
what the DUA determines is the "best" order of DSAs to query. For 
example, the DUA may choose to examine the server list and to 
query the DSAs in order based on the "closest" server or the 
server with the least amount of "load". Interpretation of the 
"best" server order is entirely up to the DUA, and not part of 
this document. 


Once the order of server addresses is determined, the DUA contacts 
the DSA specified by the first server address in the list. If 
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that DSA is unavailable, the remaining DSAs SHOULD be queried 
until an available DSA is found, or no more DSAs are available. 
If a server address or port is invalid, the DUA SHOULD proceed to 
the next server address as described just above. 


Syntax: 
serverList - hostport *(SP [hostport]) 
Default Value: 


If a defaultServerList attribute is not provided, the DUA MAY 
attempt to contact the same DSA that provided the configuration 
profile entry itself. The default DSA is contacted only if the 
preferredServerList attribute is also not provided. 


Other attribute notes: 


This attribute is used in conjunction with the preferredServerList 
attribute. Please see Section 4.1 for additional implementation 
notes. Determining how the DUA should query the DSAs also depends 
on the additional configuration attributes, credentialLevel, 
serviceCredentialLevel, bindTimeLimit, 
serviceAuthenticationMethod, and authenticationMethod. Please 
review Section 5 for details on how a DUA should properly contact 
a DSA. 


Example: 


defaultServerList: 192.168.169.170 ldapl.mycorp.com 
1dap2:1389 [1080::8:800:200C:417A] :5912 


4.3. Interpreting the defaultSearchBase Attribute 
Interpretation: 
When a DUA needs to search the DSA for information, this attribute 
provides the base for the search. This parameter can be 
overridden or appended by the serviceSearchDescriptor attribute. 
See Section 4.6. 


Syntax: 


Defined by OID 1.3.6.1.4.1.1466.115.121.1.12 [RFC4517]. 
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Default Value: 


There is no default value for the defaultSearchBase. A DUA MAY 
define its own method for determining the search base, if the 
defaultSearchBase is not provided. 


Other attribute notes: 


This attribute is used in conjunction with the 
serviceSearchDescriptor attribute. See Section 4.6. 


Example: 
defaultSearchBase: dc=mycompany, dc=com 
4.4. Interpreting the authenticationMethod Attribute 
Interpretation: 


The authenticationMethod attribute defines an ordered list of LDAP 
bind methods to be used when attempting to contact a DSA. The 
serviceAuthenticationMethod overrides this value for a particular 
service (see Section 4.15). Each method MUST be attempted in the 
order provided by the attribute, until a successful LDAP bind is 
performed ("none" is assumed to always be successful). However, 
the DUA MAY skip over one or more methods. See Section 5 for more 
information. 


none - The DUA does not perform an LDAP bind. 

simple - The DUA performs an LDAP simple bind. 

sasl - The DUA performs an LDAP Simple Authentication and 
Security Layer (SASL) [RFC4422] bind using the specified 
SASL mechanism and options. 

tls - The DUA performs an LDAP StartTLS operation followed by 


the specified bind method (for more information refer to 
Section 4.14 of [RFC4511]). 
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Syntax: 
authMethod = method *(";" method) 
method = none / simple / sasl / tls 
none = "none" 
simple = "simple" 
sasl = "sasl/" saslmech [ ":" sasloption ] 
sasloption = "auth-conf" / "auth-int" 
tls = "tls:" (none / simple / sasl) 
saslmech = SASL mechanism name as defined in [SASLMECH] 


Note: Although multiple authentication methods may be specified in 
the syntax, at most one of each type is allowed. That is, 
"simple;simple" is invalid. 


Default Value: 


If the authenticationMethod or serviceAuthenticationMethod (for 
that particular service) attributes are not provided, the DUA MAY 
choose to bind to the DSA using any method defined by the DUA. 
However, if either authenticationMethod or 
serviceAuthenticationMethod is provided, the DUA MUST only use the 
methods specified. 


Other attribute notes: 


When using TLS, the string "tls:sasl/EXTERNAL" implies that both 
client and server (DSA and DUA) authentications are to be 
performed. Any other TLS authentication method implies server- 
only (DSA side credential) authentication, along with the other 
SASL method used for DUA-side authentication. 


Determining how the DUA should bind to the DSAs also depends on 
the additional configuration attributes, credentialLevel, 
serviceCredentialLevel, serviceAuthenticationMethod, and 
bindTimeLimit. Please review Section 5 for details on how to 
properly bind to a DSA. 
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Example: 
authenticationMethod: tls:simple;sasl/DIGEST-MD5 
(see [RFC2831]) 

4.5. Interpreting the credentialLevel Attribute 

Interpretation: 
The credentialLevel attribute defines what type(s) of 
credential(s) the DUA MUST use when contacting the DSA. The 
serviceCredentialLevel overrides this value for a particular 


service (Section 4.16). The credentialLevel can contain more than 
one credential type, separated by whitespace. 


anonymous The DUA SHOULD NOT use a credential when binding to the 
DSA. 


proxy The DUA SHOULD use a known proxy identity when binding 
to the DSA. A proxy identity is a specific credential 
that was created to represent the DUA. This document 
does not define how the proxy user should be created, or 
how the DUA should determine what the proxy user's 


credential is. This functionality is up to each 
implementation. 
self When the DUA is acting on behalf of a known identity, 


the DUA MUST attempt to bind to the DSA as that 
identity. The DUA should contain methods to determine 
the identity of the user such that the identity can be 
authenticated by the directory server using the defined 
authentication methods. 


If the credentialLevel contains more than one credential type, the 
DUA MUST use the credential types in the order specified. 

However, the DUA MAY skip over one or more credential types. As 
Soon as the DUA is able to successfully bind to the DSA, the DUA 
SHOULD NOT attempt to bind using the remaining credential types. 
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Syntax: 
credentialLevel = level *(SP level) 
level = self / proxy / anonymous 
self = "self" 
proxy = "proxy" 
anonymous — "anonymous" 


Note: Although multiple credential levels may be specified in the 
syntax, at most one of each type is allowed. Refer to 
implementation notes in Section 5 for additional syntax 
requirements for the credentialLevel attribute. 


Default Value: 


If the credentialLevel attribute is not defined, the DUA SHOULD 
NOT use a credential when binding to the DSA (also known as 
anonymous). 


Other attribute notes: 


Determining how the DUA should bind to the DSAs also depends on 
the additional configuration attributes, authenticationMethod, 
serviceAuthenticationMethod, serviceCredentialLevel, and 
bindTimeLimit. Please review Section 5 for details on how to 
properly bind to a DSA. 


Example: 
credentialLevel: proxy anonymous 
4.6. Interpreting the serviceSearchDescriptor Attribute 
Interpretation: 


The serviceSearchDescriptor attribute defines how and where a DUA 
SHOULD search for information for a particular service. The 
serviceSearchDescriptor contains a serviceID, followed by one or 
more base-scope-filter triples. These base-scope-filter triples 
are used to define searches only for the specific service. 
Multiple base-scope-filters allow the DUA to search for data in 
multiple locations in the directory information tree (DIT). 
Although this syntax is very similar to the LDAP URL [RFC3986], 
this document requires the ability to supply multiple hosts as 


Neal-Joslin, et al. Informational [Page 16] 


RFC 4876 LDAP-Based Agent Configuration Schema May 2007 


part of the configuration of the DSA. In addition, an ordered 
list of search descriptors is required, which cannot be specified 
by the LDAP URL. 


The serviceSearchDescriptor might also contain the DN of an entry 
that will contain an alternate profile. The DSA SHOULD re- 
evaluate the alternate profile and perform searches as specified 
by that profile. 


If the base, as defined in the serviceSearchDescriptor, is 
followed by the "," (ASCII 0x2C) character, this base is known as 
a relative base. This relative base may be constructed of one or 
more RDN components. In this case, the DUA MUST define the search 
base by appending the relative base with the defaultSearchBase. 


Syntax: 


serviceID ":" serviceSearchDesc *(";" 
serviceSearchDesc) 


serviceSearchList 


serviceSearchDesc confReferral / searchDescriptor 


searchDescriptor = [base] ["?" [scopeSyntax] ["?" [filter]]] 
confReferral = "ref:" distinguishedName 

base = distinguishedName / relativeBaseName 
relativeBaseName = 1*(relativeDistinguishedName ",") 


filter = UTF-8 encoded string 


If the confReferral, base, relativeBaseName, or filter contains 
the ";" (ASCII 0x3B), "?" (ASCII Ox3F), """ (ASCII 0x22), or "\" 
(ASCII 0x5C) characters, those characters MUST be escaped 
(preceded by the "\" character). Alternately, the DN may be 
surrounded by quotes (ASCII 0x22). Refer to RFC 4514. If the 
confReferral, base, relativeBaseName, or filter are surrounded by 
quotes, only the """ character needs to be escaped. Any character 
that does not need to be escaped, and yet is preceded by the "\" 
character, results in both the "X" character and the character 
itself. 


The usage and syntax of the filter string MUST be defined by the 
DUA service. A suggested syntax would be that defined by 
[RFC4515]. 


Neal-Joslin, et al. Informational [Page 17] 


RFC 4876 LDAP-Based Agent Configuration Schema May 


If a DUA is performing a search for a particular service that 
a serviceSearchDescriptor defined, the DUA MUST set the base, 
Scope, and filter as defined. Each base-scope-filter triple 
represents a single LDAP search operation. If multiple base- 


2007 


has 


Scope-filter triples are provided in the serviceSearchDescriptor, 
the DUA SHOULD perform multiple search requests, and in that case, 
it MUST be in the order specified by the serviceSearchDescriptor. 


FYI: Service search descriptors do not exactly follow the LDAP URL 


syntax [RFC4516]. The reasoning for this difference is to 


Separate the host name(s) from the filter. This allows the DUA to 


have a more flexible solution in choosing its DSA. 
Default Value: 


If a serviceSearchDescriptor, or an element thereof, is not 


defined for a particular service, the DUA SHOULD create the base, 


Scope, and filter as follows: 
base - Same as the defaultSearchBase. 
Scope - Same as the defaultSearchScope. 


filter - Use defaults as defined by DUA's service. 


If the defaultSearchBase or defaultSearchScope is not defined, 


then the DUA service MAY use its own default. 
Other attribute notes: 


If a serviceSearchDescriptor exists for a given service, the 
service MUST use at least one base-scope-filter triple in 


performing searches. It SHOULD perform multiple searches per 
service if multiple base-scope-filter triples are defined for 
service. 


The details of how the "filter" is interpreted by each DUA's 
service is defined by that service. This means the filter is 
REQUIRED to be a legal LDAP filter [RFC4515]. Furthermore, 


that 


NOT 


determining how attribute and object class mapping affects that 
search filter MUST be defined by the service. That is, the DUA 


SHOULD specify if the attributes in the filter are assumed to 
already have been mapped, or if it is expected that attribute 
mapping (see Section 4.7) would be applied to the filter. In 
general practice, implementation and usability suggests that 


attribute and object class mapping (Sections 4.7 and 4.13) SHOULD 


NOT be applied to the filter defined in the 
serviceSearchDescriptor. 
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The serviceID is unique to a given service within the scope of any 
DUA that might use the given profile, and should be defined by 
that service. Registration of serviceIDs is not addressed by this 
document. However, as per the guidance at the end of Section 1, 
when DUA developers define their use of the DUAConfigProfile 
Schema, they will define the serviceIDs used by that DUA. 


searchGuide and enhancedSearchGuide [RFC4517]: 


There are a few reasons why the authors chose not to take 
advantage of the existing searchGuide and enhancedSearchGuide 
attributes and related syntaxes. While the enhancedSearchGuide 
met a number of the serviceSearchDescriptor requirements, 
serviceSearchDescriptor was developed primarily to support 
associating search operations with services. Multiple services 
could be configured using the same profile, thus requiring the 
serviceID to be specified together with the search descriptor 
information. A few other reasons for not using 
enhancedSearchGuide include: 


The need to specify alternate search bases, including the 
ability to specify search bases that are relative to the parent 
defaultSearchBase. 


The need to specify alternate profiles using the "ref:" syntax. 


The ability for individual services to specify their own 
syntaxes for the format of the search filter. 


The authors' belief that the user community is more familiar 
with the search filter syntax described by RFC 4515 than with 
that described by the enhancedSearchGuide syntax. 


Example: 


defaultSearchBase: dc=mycompany, dc=com 


serviceSearchDescriptor: email:ou=people, ou=orgl1, ? 
one; ou=contractor, ?one; 
ref:cn=profile, dc=mycompany, dc=com 


In this example, the DUA MUST search in 
"ou=people, ou=orgl, dc=mycompany,dc=com" first. The DUA then 
SHOULD search in "ou=contractor,dc=mycompany,dc=com", and finally 
it SHOULD search other locations as specified in the profile 
described at "cn=profile,dc=mycompany,dc=com". For more examples, 
see Appendix A. 
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4.7. Interpreting the attributeMap Attribute 
Interpretation: 


A DUA SHOULD perform attribute mapping for all LDAP operations 
performed for a service that has an attributeMap entry. Because 
attribute mapping is specific to each service within the DUA, a 
"serviceID" is required as part of the attributeMap syntax. That 
is, not all DUA services should necessarily perform the same 
attribute mapping. 


Attribute mapping in general is expected to be used to map 
attributes of similar syntaxes as specified by the service 
supported by the DUA. However, a DUA is NOT REQUIRED to verify 
syntaxes of mapped attributes. If the DUA does discover that the 
syntax of the mapped attribute does not match that of the original 
attribute, the DUA MAY perform translation between the original 
syntax and the new syntax. When DUAs do support attribute value 
translation, the method and list of capable translations SHOULD be 
documented in a description of the DUA service. 


Syntax: 
attributeMap = serviceID ":" origAttribute "=" attributes 
origAttribute = attribute 
attributes = wattribute *( SP wattribute ) 
wattribute = WSP newAttribute WSP 
newAttribute = descr / "*NULL*" 
attribute = descr 


Values of the origAttribute are defined by and SHOULD be 
documented for the DUA service, as a list of known supported 
attributes. 


Default Value: 
By default, attributes that are used by a DUA service are not 
mapped unless mapped by the attributeMap attributes. The DUA 


SHOULD NOT map an attribute unless it is explicitly defined by an 
attributeMap attribute. 
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Other attribute notes: 


When an attribute is mapped to the special keystring "*NULL*", the 
DUA SHOULD NOT request that attribute from the DSA, when 
performing a search or compare request. If the DUA is also 
capable of performing modification on the DSA, the DUA SHOULD NOT 
attempt to modify any attribute which has been mapped to "*NULL*". 


It is assumed the serviceID is unique to a given service within 
the scope of the DSA. 


A DUA SHOULD support attribute mapping. If it does, the following 
additional rules apply: 


1. The list of attributes that are allowed to be mapped SHOULD be 
defined by and documented for the service. 


2. Any supported translation of mapping from attributes of 
dissimilar syntax SHOULD also be defined and documented. 


3. If an attribute may be mapped to multiple attributes, the DSA 
SHOULD define a syntax or usage statement for how the new 
attribute value will be constructed. Furthermore, the 
resulting translated syntax of the combined attributes MUST be 
the same as the attribute being mapped. 


4. A DUA MUST support mapping of attributes using the attribute 
OID. It SHOULD support attribute mapping based on the 
attribute name. 


5. It is recommended that attribute mapping not be applied to 
parents of the target entries. 


6. Attribute mapping is not recursive. In other words, if an 
attribute has been mapped to a target attribute, that new 
target attribute MUST NOT be mapped to a third attribute. 


7. A given attribute MUST only be mapped once for a given 
service. 


Example: 


Suppose a DUA is acting on behalf of an email service. By default 
the "email" service uses the "mail", "cn", and "sn" attributes to 
discover mail addresses. However, the email service has been 
deployed in an environment that uses "employeeName" instead of 
"cn". Also, instead of using the "mail" attribute for email 
addresses, the "email" attribute is used. In this case, the 
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attribute "cn" can be mapped to "employeeName", allowing the DUA 
to perform searches using the "employeeName" attribute as part of 
the search filter, instead of "cn". Also, "mail" can be mapped to 
"email" when attempting to retrieve the email address. This 
mapping is performed by adding the attributeMap attributes to the 
configuration profile entry as follows (represented in LDIF 
[RFC2849]): 


attributeMap: email:cn=employeeName 
attributeMap: email:mail=email 


As described above, the DUA MAY also map a single attribute to 
multiple attributes. When mapping a single attribute to more than 
one attribute, the new syntax or usage of the mapped attribute must 
be intrinsically defined by the DUAS service. 


attributeMap: email:cn=firstName lastName 


In the above example, the DUA creates the new value by generating a 
Space-separated string using the values of the mapped attributes. In 
this case, a special mapping must be defined so that a proper search 
filter can be created. For further information on this example, 
please refer to Appendix A. 


Another possibility for multiple attribute mapping might come in 
when constructing returned attributes. For example, perhaps all 
email addresses are of a guaranteed syntax of "uid@domain". In 
this example, the uid and domain are separate attributes in the 
directory. The email service may define that if the "mail" 
attribute is mapped to two different attributes, it will construct 
the email address as a concatenation of the two attributes (uid 
and domain), placing the "@" character between them. 


attributeMap: email:mail=uid domain 


Note: The attributeMap attribute contains only a list of attribute 
names that should be mapped, not the definition of how syntax 
translation should be performed. The process used to perform 
attribute value syntax translation (such as translating a uid toa 
DN) and/or joining of multiple attribute values to form the target 
syntax (such as in the above email example) is up to the service. 
The attribute list defined in the attributeMap merely provides the 
attributes that would be used as inputs to the translation function 
provided by the service. 
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4.8. Interpreting the searchTimeLimit Attribute 


Interpretation: 


The searchTimeLimit attribute defines the maximum time, in 
seconds, that the DUA SHOULD allow for a search request to 
complete. 


Syntax: 
Defined by OID 1.3.6.1.4.1.1466.115.121.1.27 [RFC4517]. 
Default Value: 


If the searchTimeLimit attribute is not defined or is zero, the 
searchTimeLimit SHOULD NOT be enforced by the DUA. 


Other attribute notes: 
This time limit only includes the amount of time required to 
perform the LDAP search operation. If other operations are 


required, they do not need to be considered part of the search 
time. See bindTimeLimit for the LDAP bind operation. 


4.9. Interpreting the bindTimeLimit Attribute 
Interpretation: 
The bindTimeLimit attribute defines the maximum time, in seconds, 
that a DUA SHOULD allow for the bind request to complete when 


performed against each server on the preferredServerList or 
defaultServerList. 


Syntax: 
Defined by OID 1.39.6.1.4.1.1466.115.121.1.27. 
Default Value: 


If the bindTimeLimit attribute is not defined or is zero, the 
bindTimeLimit SHOULD NOT be enforced by the DUA. 


Other attribute notes: 


This time limit only includes the amount of time required to 
perform the LDAP bind operation. If other operations are 
required, those operations do not need to be considered part of 
the bind time. See searchTimeLimit for the LDAP search operation. 
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4.10. Interpreting the followReferrals Attribute 
Interpretation: 
If set to TRUE, the DUA SHOULD follow any referrals if discovered. 
If set to FALSE, the DUA MUST NOT follow referrals. 
Syntax: 
Defined by OID 1.3.6.1.4.1.1466.115.121.1.7 [RFC4517]. 
Default Value: 


If the followReferrals attribute is not set or set to an invalid 
value, the default value is TRUE. 


4.11. Interpreting the dereferenceAliases Attribute 
Interpretation: 
If set to TRUE, the DUA SHOULD enable alias dereferencing. 
If set to FALSE, the DUA MUST NOT enable alias dereferencing. 
Syntax: 
Defined by OID 1.3.6.1.4.1.1466.115.121.1.7. 
Default Value: 


If the dereferenceAliases attribute is not set or set to an 
invalid value, the default value is TRUE. 


4.12. Interpreting the profileTTL Attribute 
Interpretation: 
The profileTTL attribute defines how often the DUA SHOULD reload 
and reconfigure itself using the corresponding configuration 
profile entry. The value is represented in seconds. Once a DUA 


reloads the profile entry, it SHOULD reconfigure itself with the 
new values. 


Syntax: 


Defined by OID 1.3.6.1.4.1.1466.115.121.1.27. 
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Default Value: 
If not specified, the DUA MAY use its own reconfiguration policy. 
Other attribute notes: 


If the profileTTL value is zero, the DUA SHOULD NOT automatically 
reload the configuration profile. 


4.13. Interpreting the objectclassMap Attribute 
Interpretation: 


A DUA MAY perform object class mapping for all LDAP operations 
performed for a service that has an objectclassMap entry. Because 
object class mapping is specific for each service within the DUA, 
a "serviceID" is required as part of the objectclassMap syntax. 
That is, not all DUA services should necessarily perform the same 
object class mapping. 


Object class mapping SHOULD be used in conjunction with attribute 
mapping to map the schema required by the service to an equivalent 
Schema that is available in the directory. 


Object class mapping may or may not be required by a DUA. Often, 
the objectclass attribute is used in search filters. Section 4.7 
recommends that attribute mapping not be applied to the 
serviceSearchDescriptor. Thus, if the default object classes are 
not used in a DUA deployment, typically only the 
serviceSearchDescriptor needs to be defined to reflect that 
mapping. However, when the service search descriptor is not 
provided, and the default search filter for that service contains 
the objectclass attribute, that search filter SHOULD be redefined 
by object class mapping, if defined. If a default search filter 
is not used, it SHOULD be redefined through the 
serviceSearchDescriptor. If a serviceSearchDescriptor is defined 
for a particular service, it SHOULD NOT be remapped by either the 
objectclassMap or attributeMap values. 


One condition where the objectclassMap SHOULD be used is when the 
DUA is providing gateway functionality. In this case, the DUA is 
acting on behalf of another service, which may pass in a search 
filter itself. In this type of DUA, the DUA may alter the search 
filter according to the appropriate attributeMap and 
objectclassMap values. In this case, it is also assumed that a 
serviceSearchDescriptor is not defined. 
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Syntax: 
objectclassMap = serviceID ":" origObjectclass "=" objectclass 
origObjectclass = objectclass 
objectclass = keystring 


Values of the origObjectclass depend on the type of DUA Service 
using the object class mapping feature. 


Default Value: 


The DUA MUST NOT remap an object class unless it is explicitly 
defined by an objectclassMap attribute. 


Other attribute notes: 


A DUA SHOULD support object class mapping. If it does, the DUA 
MUST support mapping of object classes using the objectclass OID. 
It SHOULD support object class mapping based on the object class 
name. 


It is assumed the serviceID is unique to a given service within 
the scope of the DSA. 


Example: 
Suppose a DUA is acting on behalf of an email service. By default 


the "email" service uses the "mail", "cn", and "sn" attributes to 
discover mail addresses in entries created using inetOrgPerson 


object class [RFC2789]. However, the email service has been 
deployed in an environment that uses entries created using 
"employee" object class. In this case, the attribute "cn" can be 


mapped to "employeeName", and "inetOrgPerson" can be mapped to 
"employee", allowing the DUA to perform LDAP operations using the 
entries that exist in the directory. This mapping is performed by 
adding attributeMap and objectclassMap attributes to the 
configuration profile entry as follows (represented in LDIF 
[RFC2849]): 


attributeMap: email:cn=employeeName 
objectclassMap: email:inetOrgPerson=employee 


Neal-Joslin, et al. Informational [Page 26] 


RFC 4876 LDAP-Based Agent Configuration Schema May 2007 


4.14. Interpreting the defaultSearchScope Attribute 

Interpretation: 
When a DUA needs to search the DSA for information, this attribute 
provides the "scope" for the search. This parameter can be 
overridden by the serviceSearchDescriptor attribute. See 
Section 4.6. 

Syntax: 
ScopeSyntax - "base" / "one" / "sub" 


Default Value: 


The default value for the defaultSearchScope SHOULD be defined by 


the DUA service. If the default search scope for a service is not 
defined, then the scope SHOULD be for the DUA to perform a subtree 
search. 


4.15. Interpreting the serviceAuthenticationMethod Attribute 


Interpretation: 


The serviceAuthenticationMethod attribute defines an ordered list 
of LDAP bind methods to be used when attempting to contact a DSA 


for a particular service. Interpretation and use of this 
attribute is the same as Section 4.4, but specific for each 
service. 

Syntax: 
svAuthMethod = serviceID ":" method *(";" method) 


Note: Although multiple authentication methods may be specified in 
the syntax, at most one of each type is allowed. 


Default Value: 


If the serviceAuthenticationMethod attribute is not provided, the 
authenticationMethod SHOULD be followed, or its default. 


Other attribute notes: 


Determining how the DUA should bind to the DSAs also depends on 
the additional configuration attributes, credentialLevel, 
serviceCredentialLevel, and bindTimeLimit. Please review 
Section 5 for details on how to properly bind to a DSA. 
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Example: 


serviceAuthenticationMethod: email:tls:simple;sasl/DIGEST-MD5 
4.16. Interpreting the serviceCredentialLevel Attribute 


Interpretation: 
The serviceCredentialLevel attribute defines what type(s) of 


credential(s) the DUA SHOULD use when contacting the DSA for a 
particular service. Interpretation and use of this attribute are 


the same as Section 4.5. 


Syntax: 


svCredentialLevel = serviceID ":" level *(SP level) 


Refer to implementation notes in Section 5 for additional syntax 
requirements for the credentialLevel attribute. 


Note: Although multiple credential levels may be specified in the 
syntax, at most one of each type is allowed. 


Default Value: 


If the serviceCredentialLevel attribute is not defined, the DUA 
MUST examine the credentialLevel attribute, or if one is not 
provided, the DUA must follow its default. 


Other attribute notes: 


Determining how the DUA should bind to the DSAs also depends on 
the additional configuration attributes, 
serviceAuthenticationMethod, authenticationMethod, and 
bindTimeLimit. Please review Section 5 for details on how to 


properly bind to a DSA. 


Example: 


serviceCredentialLevel: email:proxy anonymous 
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5. Binding to the Directory Server 


The DUA SHOULD use the following algorithm when binding to the 


server: 
for (clevel in credLevel) [see Note 1] 
if (clevel is "anonymous") 
for (host in hostnames) [see Note 2] 


if (server is responding) 
return success 
return failure 
else 
for (amethod in authMethod) [see Note 3] 
if (amethod is none) 
for (host in hostnames) 
if (server is responding) 
return success 
return failure 
else 
for (host in hostnames) 
authenticate using amethod and clevel 
if (authentication passed) 
return success 
return failure 


Note 1: The credLevel is a list of credential levels as defined in 
serviceCredentialLevel (Section 4.16) for a given service. 
If the serviceCredentialLevel is not defined, the DUA MUST 
examine the credentialLevel attribute. 


Note 2: hostnames is the list of servers to contact as defined in 
Sections 4.1 and 4.2. 


Note 3: The authMethod is a list of authentication methods as 
defined in serviceAuthenticationMethod (Section 4.15) for a 
given service. If the serviceAuthenticationMethod is not 
defined, the DUA MUST examine the authenticationMethod 
attribute. 


6. Security Considerations 


The profile entries MUST be protected against unauthorized 
modification. Each service needs to consider implications of 
providing its service configuration as part of this profile and limit 
access to the profile entries accordingly. 
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The management of the authentication credentials for the DUA is 
outside the scope of this document and needs to be handled by the 
DUA. 


Since the DUA needs to know how to properly bind to the directory 
server, the access control configuration of the DSA MUST assure that 
the DSA can view all the elements of the DUAConfigProfile attributes. 
For example, if the credentialLevel attribute contains "Self", but 
the DSA is unable to access the credentialLevel attribute, the DUA 
will instead attempt an anonymous connection to the directory server. 


The algorithm described by Section 5 also has security 
considerations.  Altering that design will alter the security aspects 
of the configuration profile. 


At times, DUAs connect to multiple directory servers in order to 
support potential high-availability and/or performance requirements. 
As such, each directory server specified in the preferredServer list 
and defaultServerList MUST contain the same (replicated) data and be 
part of the same security domain. This means the directory-supported 
authentication methods, authentication policies, and access control 
policies for directory data are exactly the same across all the 
defined directory servers. 
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8. IANA Considerations 


This document defines new LDAP attributes and an object class for 
object identifier descriptors. As specified by Section 3.4 and 
required by Section 4 of [RFC4520], this document registers new 
descriptors as follows per the Expert Review. 
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8.1. Registration of Object Classes 
Subject: Request for LDAP Descriptor Registration 
Descriptor (short name): DUAConfigProfile 
Object Identifier: 1.3.6.1.4.1.11.1.3.1.2.5 


Person & email address to contact for further information: 
See "Author/Change Controller" 


Usage: object class 


Specification: RFC 4876 


Author/Change Controller: 


Bob Neal-Joslin 
Hewlett-Packard Company 
19420 Homestead RD 
Cupertino, CA 95014 

USA 

Phone: +1 408-447-3044 
EMail: bob_joslin@hp.com 


Comments: 
See also the associated request for the defaultServerList, 
defaultSearchBase, preferredServerList, searchTimeLimit, 
bindTimeLimit, followReferrals, authenticationMethod, 
profileTTL, attributeMap, credentialLevel, objectclassMap, 
defaultSearchScope, serviceCredentialLevel, 
serviceSearchDescriptor, serviceAuthenticationMethod, and 
dereferenceAliases attribute types. 

8.2. Registration of Attribute Types 
Subject: Request for LDAP Descriptor Registration 
Descriptor (short name): See comments 


Object Identifier: See comments 


Person & email address to contact for further information: 
See "Author/Change Controller" 


Usage: attribute type 
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Specification: RFC 4876 


Author/Change Controller: 


Bob Neal-Joslin 
Hewlett-Packard Company 
19420 Homestead RD 
Cupertino, CA 95014 

USA 

Phone: +1 408-447-3044 
EMail: bob joslin8hp.com 


Comments: 


The following object identifiers and associated attribute 
types have been registered. 


OID Attribute Type 
l23.60.1:42:1. le 3 dat. 0 defaultServerList 

cee Be sed een erga Ul er Epes Eo pre ore h defaultSearchBase 
123.6124. Te VT 1:3. 20.2 preferredServerList 
e362 4 44.4411. foe Lk. 3 searchTimeLimit 
13601. Ald St ole bindTimeLimit 

18306401 A DE s uaa 5 followReferrals 

1523.0 0 4 1-114. 153.12:714:6 authenticationMethod 
l32364 0150.01. 105.1:3-1275.7 profileTTL 
1:3.6-I4:1:1T7T27:3.05.1.9 attributeMap 

l2346:Il92- 15 bl.t.3:1L. 5.430 credentialLevel 
123.60. 4 Mid, We Sins Lie Dee objectclassMap 

TEESE Ol Asda eb 3. de he 2 defaultSearchScope 
]1c3200L.4 1.11.13 .14214135 serviceCredentialLevel 
l23.60:1.42.1:1L.-1.3:1:.1.14 serviceSearchDescriptor 
e326. 154.44 Lele leh. LS serviceAuthenticationMethod 
145352601:42T;.LY1.1.3.1;1.16 dereferenceAliases 


Please also see the associated registration request for the 
DUAConfigProfile object class. 
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Appendix A. Examples 


In this section, we will describe a fictional DUA that provides one 
service, called the "email" service. This service would be similar 
to an email client that uses an LDAP directory to discover email 
addresses based on a textual representation of the recipient's 
colloquial name. 


This email service is defined by default to expect that users with 
email addresses will be of the "inetOrgPerson" object class type 
[RFC2789]. And by default, the "email" service expects the 
colloquial name to be stored in the "cn" attribute, while it expects 
the email address to be stored in the "mail" attribute (as one would 
expect as defined by the inetOrgPerson object class). 


As a special feature, the "email" service will perform a special type 
of attribute mapping when performing searches. If the "cn" attribute 
has been mapped to two or more attributes, the "email" service will 
parse the requested search string and map each whitespace-separated 
token into the mapped attributes, respectively. 


The default search filter for the "email" service is 
"(objectclass-inetOrgPerson)". The email service also defines that 
when it performs a name-to-address discovery, it will wrap the search 
filter inside a complex search filter as follows: 


(& (<filter>) (cn^-«name string>) ) 


Or, if "cn" has been mapped to multiple attributes, that wrapping 
would appear as follows: 


(&(«filter») (attrl -«token1») (attr2 -«token2»)...) 


The below examples show how the "email" service builds its search 


requests, based on the defined profile. In all cases, the 
defaultSearchBase is "o-airius.com", and the defaultSearchScope is 
undefined. 


In addition, for all examples, we assume that the "email" service has 
been requested to discover the email address for "Jane Hernandez". 


Example 1: 
serviceSearchDescriptor: email:"ou=marketing," 
base: ou=marketing, o=airius.com 


scope: sub 
filter: (&(objectclass-inetOrgPerson) (cn^-Jane Hernandez) ) 
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Example 2: 


serviceSearchDescriptor: email:"ou=marketing,"?one? 
(& (objectclass=inetOrgPerson) (c=us) ) 
attributeMap: email:cn=2.5.4.42 sn 


Note: 2.5.4.42 is the OID that represents the "givenName" 
attribute. 


In this example, the email service performs <name string> parsing as 
described above to generate a complex search filter. The above 
example results in one search. 


base: ou=marketing, o=airius.com 

scope: one 

filter: (&(& (objectclass=inetOrgPerson) (c=us) ) 
(2.5.4.42^-Jane) (sn^-Hernandez)) 


Example 3: 


serviceSearchDescriptor: email:ou=marketing, "?base 
attributeMap: email:cn=name 


This example is invalid, because either the quote should have 
been escaped, or there should have been a leading quote. 


Example 4: 


serviceSearchDescriptor: email:ou=\\mar\\\\keting, \\"?base 
attributeMap: email:cn=name 


base: ou=\\mar\\keting," 
scope: base 


filter (&(objectclass-inetOrgPerson) (name~=Jane Hernandez) ) 


Example 5: 


serviceSearchDescriptor: email:ou="marketing", o=supercom 


This example is invalid, since the quote was not a leading quote, 
and thus should have been escaped. 
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Example 6: 


serviceSearchDescriptor: email:??(& (objectclass=person) 
(ou=Orgl \\\\(temporary\\\\))) 


base: o=airius.com 

scope: sub 

filter: (&((& (objectclass=person) (ou=Orgl \\(Temporary\\))) 
(cn^-Jane Henderson) ) ) 

Example 7: 

serviceSearchDescriptor: email:"ou-funny?org," 

base: ou-funny?org,o-airius.com 


scope: sub 
filter (&(objectclass-inetOrgPerson) (cn^-Jane Hernandez) ) 
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